home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1991 / Jan 91 / MacApp.Tech$ 1⁄18⁄91 / 2675-View⁄Data Aritecture-Jan91 < prev    next >
Encoding:
Text File  |  1991-03-06  |  3.0 KB  |  61 lines  |  [TEXT/GEOL]
  1. Item    3221192                         15-Jan-91        06:38PST
  2.  
  3. From:   KRIPALU                         Kripalu Ctr, Michael A Latta,PRT
  4.  
  5. To:     ALGER                           Alger, Jeff,VCA
  6.         DEREK                           White, Derek
  7.  
  8. cc:     MACAPP.TECH$                    MacApp Technical
  9.  
  10. Item forwarded by       SPA.DTS      to SPA0144 
  11.  
  12. ------------------------------------------------------------------------------
  13.  
  14. Sub:    View/Data Aritecture Problem
  15.  
  16. MacAppers:
  17.  
  18.     I would like to present a problem and see what others think of it.  This
  19. has some bearing on the Pascal 9x report as well.
  20.  
  21.     The current MacApp architecture assumes that the view must know the class
  22. of the object that is being displayed, and further must know the method that is
  23. to be used to access and update that data.  This results in coding a view for
  24. every new data object.  In our application and I imagine others there are a lot
  25. of compound objects that we would like to display using standard views (text,
  26. money, numbers, dates, etc.)  Further I feel the application design is best if
  27. the view is not pointed directly to the atomic data but at the logical target
  28. of the view so that the application implementation of these compound objects
  29. can be hidden from the rest of the system.
  30.     In Smalltalk these are called Pluggable Views.  They are provided the
  31. selectors that retreive and return data and they care not at all what class the
  32. target is or what specific selector is used.  I can imagine that Method
  33. Pointers in the Pascal 9x report were intended to support fledability in this
  34. direction.  What I do not see is how they will in reality help at all.  I may
  35. have missed something in the description but since the class of the receiving
  36. object is part of the pointer declaration the view still must know the class of
  37. object that will be it's target, and because the method must be implemented by
  38. that class the pointer can not allow the view to be ignorant of the fact that
  39. the method is really a subclass's specific field accessor.  These pointers
  40. would remove the case statemnt from DoChoice type methods where the selector
  41. indicates the action taken by the user, but they do not allow the method to
  42. represent the result desired.
  43.  
  44.     I can not as defined provide to a generic object the method that controls
  45. the desired result in the target object.  It is still up to the target to
  46. decide how to respond to user interface actions.  This is a basic violation
  47. that data objects should be isolated from the user interface.  It also does not
  48. deal with the problem of multiple similar objects that desire different
  49. results.  Thus the target must still decide which button was pressed as the
  50. method can not be unique to the target but must match the general (TDocument?)
  51. target class for which the method pointer was declared.
  52.  
  53.     Having worked with Smalltalk this is the largest source of frustration in
  54. my working with MacApp.  This is even more an issue than garbage collection
  55. (letting the computer do what it is good at, humans being historically bad at
  56. managing storage).
  57.  
  58. Mike Latta
  59. KRIPALU
  60.  
  61.